iT邦幫忙

2024 iThome 鐵人賽

DAY 25
0

昨天介紹了 Message Queue 的基本功能與架構, 今天繼續介紹在此之上延伸出更具擴展性的 Event Streaming Platform (ESP) 如 Kafka, Pulsar
(題外話: 雖然講到 Message Queue 時, 很多人會直接想到 Kafka, 但嚴格來說 Kafka 並非 Message Queue, 而是 "具有 Message Queue 功能的 Event Streaming Platform")

來釐清一些特性的差別

Consuming Pattern (消費型態)

相較於 Message Queue 的 event 通常在被 消費者 讀取 / 處理後就刪除 (通常是 in-memory), 如前篇提過的 P2P Pattern 和 Pub/Sub Pattern

ESP 則會將 event 儲存起來 (持久化), 以便在未來發生錯誤時進行 回放 (Replay), 這對於擴展性有很大的提升: 新加入 / 重新上線的節點可以從 "最後一次紀錄的 event" 開始, 往後處理下線時沒處理到的事件以同步狀態, 所以可以動態的更新系統的拓墣結構

Realtime Process (即時處理)

相較於 Message Queue 通常會等到 event 累積到一定數量才 "批次處理", ESP 則讓消費者能夠 "即時處理收到的 event", 雖然 Pub/Sub Pattern 也能達到類似的效果, 但擴展性沒有 ESP 好

分散式架構

ESP 天生就支援分散式架構, 所以更容易擴展, 可用性也比一般 Message Queue 好

Topic (主題)

ESP 將 event 根據 Topic 分類, 比如 訂單, 庫存等等, 多個生產者可以發送 event 給該 Topic, 多個消費者也可以訂閱該 Topic, 並且支援 Consumer Group (消費者集群) 的概念

Consumer Group (消費者集群)

相較於一般 Message Queue 的 Pub/Sub Pattern 中所有訂閱相同 Topic 的消費者都會收到該 Topic 生產者發送的 event

ESP 則允許將 Topic 再分割成 Partitions, 分別給不同的 Consumer Group 處理以提高效率

https://ithelp.ithome.com.tw/upload/images/20240825/20161950HDtCJJjDVo.png

Partition

相同 Topic 中的 event 可以再分割成 Partitions, 並且 "每個 Partition 內的 event 是有序的", 但是 "不保證 Partitions 之間的 event 順序"

Reference


上一篇
[Day 24] Message Queue (二)
下一篇
[Day 26] Scaling Database (一)
系列文
30 天 系統設計 學習筆記:建立思考的 SOP30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言